Visualization of data dependency in graphical models

ABSTRACT

In an illustrative embodiment, an apparatus, computer-readable media, or method may be configured to suggest determine relationships. Interaction with a block diagram model may include receiving a first portion of a block diagram model. The block diagram model may include a plurality of blocks. Each of the plurality of blocks may represent a set of dynamic equations. The interacting may be performed using the computer. Relationships between a plurality of a synthesized input, a synthesized output, a synthesized state, or a synthesized derivative, may be determined. A determination may be performed for the first portion of the block diagram model. The determining may include determining a block Jacobian pattern of relationships between two or more of an input, an output, a state, or a derivative of a first block of the plurality of blocks in the graphical model.

This patent application is related to the co-filed application entitled“GRAPH THEORETIC LINEARIZATION AND SENSITIVITY ANALYSIS,” which ishereby incorporated by reference in its entirety.

BACKGROUND SECTION

A variety of dynamic systems exist, including systems forcommunications, controls, signal processing, video processing, and imageprocessing. As systems have become more complicated, the development andtesting of these systems have also become more complicated. Accordingly,computational tools have been developed to help model, simulate, andanalyze systems.

In one approach to modeling, simulating and analyzing systems,computational tools may represent systems as graphical models. Systemsmay be graphically modeled by decomposing components of the system intoindividual blocks. These blocks may then be connected to one another toform a block diagram model representing a system.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more embodiments of theinvention and, together with the description, explain one or moreillustrative embodiments of the invention. In the drawings,

FIG. 1 illustrates an example system for a graphically-based technicalcomputing environment according to an illustrative embodiment;

FIG. 2 illustrates an exemplary block diagram model according to anillustrative embodiment;

FIG. 3 illustrates an example data dependency path according to anillustrative embodiment;

FIG. 4 illustrates an example data dependency path of an integratoraccording to an illustrative embodiment;

FIG. 5 illustrates an example data dependency path of a gain blockaccording to an illustrative embodiment;

FIG. 6 illustrates an example data dependency path of a sum blockaccording to an illustrative embodiment;

FIG. 7 illustrates an example data dependency path of the block diagrammodel of FIG. 2 according to an illustrative embodiment;

FIG. 8 illustrates exemplary processing for visualizing data dependencyinformation according to an illustrative embodiment;

FIG. 9 illustrates an example block diagram model according to anillustrative embodiment;

FIG. 10 illustrates an example graphical representation of a combinedcontrol flow/data flow graph (CDFG) according to an illustrativeembodiment;

FIG. 11 illustrates an example graphical representation of a Jacobianpattern based on the dependencies in the block in FIG. 9 according to anillustrative embodiment;

FIG. 12 illustrates an example block diagram model according to anillustrative embodiment;

FIG. 13 illustrates exemplary processing for indicating datadependencies in a visualization according to an illustrative embodiment;

FIG. 14 illustrates an example block diagram model of an electricalcircuit according to an illustrative embodiment;

FIG. 15 illustrates a model showing dependency in the model according toan illustrative embodiment;

FIG. 16 illustrates a model showing a cyclic relationship according toan illustrative embodiment;

FIG. 17 illustrates a model view mode of a model according to anillustrative embodiment;

FIG. 18 illustrates a Jacobian pattern view mode of a model according toan illustrative embodiment;

FIG. 19 illustrates an example user interface displaying multiplevisualizations according to an illustrative embodiment;

FIG. 20 illustrates an example block dot Jacobian pattern visualizationaccording to an illustrative embodiment;

FIG. 21 illustrates a model visualizing model aspects according to anillustrative embodiment;

FIG. 22 illustrates a hierarchical visualization of a model in anillustrative embodiment;

FIG. 23 illustrates an example data dependency diagram visualizationaccording to an illustrative embodiment;

FIG. 24 illustrates exemplary processing for displaying multiplevisualizations according to an illustrative embodiment;

FIG. 25 illustrates a distributed environment that may be configured topractice an illustrative embodiment; and

FIG. 26 illustrates an example of a computer system that may beconfigured to practice an illustrative embodiment.

DETAILED DESCRIPTION Overview

Computational tools may help users model, simulate, and/or analyzedynamic systems by representing the systems as graphical models.Graphical models may be block diagram models composed of connectedindividual blocks. Graphical model based computational tools may beprovided for a technical computing environment and may allow a user tomodify a system. For example, a user may change blocks or connections inthe block diagram model.

However, in block diagram models with many blocks and/or manyconnections, it may be difficult for a user to determine how a blockdiagram model should be modified. For example, a user may determine thatthe output value of a block must be increased; however, the user mayneed to know what portions of the block diagram model the output valueof the block is dependent on so that the user may modify the outputvalue. Otherwise, it may be difficult for the user to obtain the desiredeffect when the model is simulated. Exemplary embodiments can providecomputational tools that determine what portions of the block diagrammodel an output is dependent on. Embodiments may further visuallyindicate these dependencies to the user.

Illustrative System

FIG. 1 illustrates an example system for graphically-based technicalcomputing environment (TCE) 100 according to an illustrative embodiment.TCE 100 may include block diagram model 110, data dependencydetermination tool 112, data dependency visualization tool 120, andsimulator 130. Model 110 may include one or more blocks, where the oneor more blocks may represent one or more dynamic equations. The blocksof block diagram model 110 may have functionality, behavior, logic,semantics, computations, and/or execution behavior defined by text, aprogramming language diagrams, computer code, discrete event systemspecification (DEVS), hardware logic, etc. Model 110 may also behierarchical. For example, a portion of model 110 may itself be a blockwithin a larger second portion of model 110.

Determination tool 112 may interact with model 110. For example,determination tool 120 may generate data dependencies for model 110. Thedata dependencies of model 110 may be determined based on the datadependency of the blocks that make up model 110. A portion of model 110may comprise a graphical model such as a time-based block diagram, anoncausal diagram, a state transition diagram, an activity diagram, adataflow diagram, a control flow diagram, a state transition matrix, atruth table, a Petri net, and a discrete event network (e.g., a DEVSdiagram). A portion of model 200 may include the entire model or part ofmodel 200.

Visualization tool 120 may interact with model 110 and determinationtool 112. Visualization tool 120 may visualize data dependenciesdetermined by determination tool 112 for model 110. Visualization tool120 may visualize various types of visualizations, as described below.

Simulator 130 may execute model 110. Data dependencies in model 110 maychange during simulation or execution of model 110. One reason forchanges may be that data dependencies may be affected by conditionalrelations, such as a relation between input and output of a subsystem.Accordingly, determination tool 112 may re-determine data dependenciesduring execution of model 110 by simulator 130 and the re-determineddata dependencies may be visualized by visualization tool 120.

Illustrative Block Diagram Model

FIG. 2 illustrates an exemplary block diagram model 200. Model 200includes multiple blocks and multiple connections.

Model 200 includes an integrator block 210, a second integrator block212, a third integrator block 214, a sum block 216, and a gain block218. An input of integrator block 210 is connected to the output of sumblock 216 by connection 220. An output of integrator block 210 isconnected to an input of sum block 216 by connection 222.

Data dependencies associated with integrator block 210 may be reportedby indicating connections 220 and 222 and sum block 216, for example byhighlighting the connections 220 and 222 and sum block 216.

Data dependencies may also be distinguished (e.g., visually highlighted)between two or more of a synthesized input, synthesized output,synthesized state, or synthesized derivative of the portion of model200. The term synthesized is used because the synthesized input,synthesized output, synthesized state, and synthesized derivative maynot correspond with an actual input, output, state, or derivative of theportion of model 200.

A synthesized input may be an input defined by a user. A synthesizedoutput may be an output defined by the user. A synthesized state may bea state defined by the user. A synthesized derivative may be aderivative defined by the user. Other embodiments may allow thesynthesized input, synthesized output, synthesized state, and/orsynthesized derivative to be pre-defined and/or programaticallydetermined.

Model 200 may represent a dynamic system. Dynamic systems may be modeledin simulation environments as sets of differential, difference, and/oralgebraic equations. These equations may be either in explicit orimplicit form. At any given instant of time, these equations may beviewed as relationships between the system's output response(“outputs”), the system's input stimuli (“inputs”) at that time, thecurrent state of the system, the system parameters, and time. The stateof the system may be thought of as a numerical representation of thedynamically changing data and/or configuration of the system. Forinstance, a signal-processing system that filters a signal may maintaina set of previous inputs as the state. The system parameters may be thenumerical representation of the static (unchanging) data and/orconfiguration of the system and may be viewed as constant coefficientsin the system's configuration.

The sample time may be the time interval at which the inputs, state, oroutputs (collectively referred to as the results) of the system may betraced as time progresses. Each of the inputs, state, and outputs mayhave a different sample time and all the different sample times may havea common base rate. A discrete-time system may be a system in which theevolution of the system results may be tracked at finite intervals oftime. In the limit as the interval approaches zero, the discrete-timesystem may become a continuous-time system. The intervals of time may beperiodic or non-periodic. Sometimes non-periodic rate systems may bereferred to as non-uniform rate systems, meaning that there is noperiodic rate at which the response may be tracked. Non-uniform-ratesystems may fall into the class of composite systems where an additionalequation (GetTimeOfNextVarHit) may define when in the future the otherequations associated with the system should be evaluated.

A model block in model 200 may be represented by the equations:

$\begin{matrix}\left\{ \begin{matrix}{\overset{.}{x} = {f\left( {x,u,t} \right)}} \\{y = {g\left( {x,u,t} \right)}}\end{matrix} \right. & (1)\end{matrix}$

These equations may also be known as a set of dynamic equations.Equations (1) are based on state x of the model block, input u of themodel block, and time t. Time-derivative, or derivative, {dot over (x)}of the model block is determined by function ƒ. Output y of the modelblock is determined by function g. Derivative {dot over (x)}, state x,input u, and output y may also be referred to as variables of the modelblock.

In a continuous-time model block, the equation for {dot over (x)} iscalled a derivative function, and the equation for y is called an outputfunction. For a discrete-time model block, the derivative equation maybe replaced by an update function and the time derivative variable by atime delay variable. For simplicity, continuous-time systems aredescribed herein, but techniques described herein may be applied todiscrete-time systems, discrete-event systems, and hybrid systems.Hybrid systems may be dynamic systems that contain both continuous anddiscrete states, for example, continuous-time and discrete-time states.

Further, derivatives do not need to be derivatives with respect to time.For example, derivatives may be with respect to distance where thederivative may be a partial derivative. In addition to PartialDifferential Equations (PDEs), techniques may also apply to Differentialand Algebraic Equations (DAEs) where the derivative {dot over (x)} inequations (1) may be multiplied by a matrix other than the identitymatrix.

Derivatives of equations (1) may be derived with respect to state x,input u to determine the effect of state x, input u on derivative {dotover (x)}, and output y of the block.

A Jacobian matrix for the model block may be defined as a matrix ofpartial derivatives of the function ƒ with respect to state x and inputu, and function g with respect to state x and input u:

$\begin{matrix}{J = {\begin{bmatrix}\frac{\partial f}{\partial x} & \frac{\partial f}{\partial u} \\\frac{\partial g}{\partial x} & \frac{\partial g}{\partial u}\end{bmatrix} = \begin{bmatrix}A & B \\C & D\end{bmatrix}}} & (2)\end{matrix}$

The Jacobian matrix may include derivatives with respect to synthesizedstate and/or input values. For example, a synthesized state may bedetermined by an algebraic relation between states of one or more modelblocks described by equation (1).

As can be seen in equation (2), the Jacobian matrix J may be made ofJacobian block matrices A, B, C, and D.

Jacobian block matrix A may be determined from the partial derivative offunction ƒ with respect to state x. Jacobian block matrix B may bedetermined from the partial derivative of the ƒ function with respect toinput u. Jacobian block matrix C may be determined from the partialderivative of function g with respect to state x. Lastly, Jacobian blockmatrix D may be determined from the partial derivative of function gwith respect to input u.

In general, a Jacobian matrix is a time varying matrix as the values ofits matrix elements may change over time. However, for some functions,some of the elements in a Jacobian matrix may always be zero. Forexample, consider the following functions:

$\begin{matrix}\left\{ \begin{matrix}{{\overset{.}{x}}_{1} = x_{2}^{2}} \\{{\overset{.}{x}}_{2} = {x_{1} + x_{2}}}\end{matrix} \right. & (3)\end{matrix}$

The Jacobian block matrix A represents how {dot over (x)}₁ and {dot over(x)}₂ depend on x₁ and x₂. For the function above, the A matrix is:

$\begin{matrix}{A = {\begin{bmatrix}0 & {2x_{2}} \\1 & 1\end{bmatrix}.}} & (4)\end{matrix}$

A₁₁ corresponds to the effect of x₁ on x₁. A₁₂ corresponds to the effectof x₂ on {dot over (x)}₂. A₂₁ and A₂₂ correspond to the effect of x₁ andx₂ on {dot over (x)}₂, respectively.

In this example, A₁₁, the upper left element in the matrix may always bezero. Such elements that are always zero may be called “hard zeroes.” Onthe other hand, A₁₂=2x₂. Accordingly, A₁₂ could be zero if x₂ is zero.Elements that may sometimes be zero may be called “soft zeroes.”

From a Jacobian matrix, a corresponding pattern matrix may beconstructed, for example, by replacing any non-hard zero elements in theJacobian matrix by a one. In another embodiment, a Boolean matrix may becreated in which the non-hard zero elements may be replaced by True andthe hard zero elements by False. The pattern matrix may reflect thestructure or data dependency in a block or system of equations. Usersmay find that the use of pattern equations allows them to visualizeaspects of structures and/or data dependencies within a block/system. Aconstructed pattern matrix may be called a Jacobian pattern, or asparsity pattern matrix. For a Jacobian block matrix, the pattern matrixmay also be referred to as a Jacobian block pattern. For the aboveexample, the block Jacobian pattern A_(p) of the Jacobian block matrix Amay be:

$\begin{matrix}{A_{p} = \begin{bmatrix}0 & 1 \\1 & 1\end{bmatrix}} & (5)\end{matrix}$

where p stands for pattern.

For example, A_(p,11)=0 means that in the above equations, x₁ is notneeded for the computation of {dot over (x)}₁. In other words, {dot over(x)}₁ is not dependent on x₁. A_(p12)=1 means {dot over (x)}₁ depends onx₂. As can be seen in the function for {dot over (x)}₁, {dot over (x)}₁is calculated based on x₂. If {dot over (x)}₁ is based on x₂, {dot over(x)}₁ may also be referred to as reachable from x₂.

The Jacobian block patterns may be calculated based on equations thatblocks represent. Jacobian block patterns may also be pre-defined. Inthe case where the block Jacobian pattern is pre-defined, the patternmay be defined by an author of a model block. For example, the authormay specify a boolean-valued pattern matrix, edge list, incident list,etc., from which the pattern may be inferred. The specification may bein graphical and/or textual form. The specification may then beretrievable when needed. For a block defined by the functions:

$\begin{matrix}\left\{ \begin{matrix}{\overset{.}{x} = {f\left( {x,u,t} \right)}} \\{y = {g\left( {x,u,t} \right)}}\end{matrix} \right. & (6)\end{matrix}$

the data dependency of the above equations may be defined based onBoolean-values as:

{dot over (x)}←A _(p) x+B _(p) u

y←C _(p) x+D _(p) u  (7)

where ‘+’ may be evaluated as ‘or’.

Given A_(p,mn) where m represents a row and n represents a column in theJacobian pattern A^(p), A_(p,mn)=1 means {dot over (x)}_(m) depends onx_(n), meaning x_(n), appears in the right hand side of the equation tocompute {dot over (x)}_(m). In other words, {dot over (x)}_(m) can bereached from x_(n).

Similarly, B_(p,mn)=1 means {dot over (x)}_(m) depends on u_(n), meaningu_(n) appears in the right-hand side of the equation to compute {dotover (x)}_(m). Correspondingly, C_(p,mn)=1 means y_(m) depends on x_(n),meaning x_(n), appears in the right hand side of the equation to computey_(m). Likewise, D_(p,mn)=1 means y_(m) depends on u_(n), meaning u_(n)appears in the right hand side of the equation to compute y_(m).

Illustrative Examples of Data Dependency Graphs

Data dependencies in blocks may be visualized as data dependency paths.

FIG. 3 illustrates example data dependency graph 300 according to anillustrative embodiment. Graph 300 may visually represent variables anddependencies between variables. As can be seen in graph 300, first node302 may represent y, second node 304 may represent x, third node 306 mayrepresent {dot over (x)}, and fourth node 308 may represent u. Further,edges may represent A_(p), B_(p), C_(p), and D_(p). As can be seen bythe edges and nodes in graph 300, y is dependent on x according to C_(p)and dependent on u according to D_(p). Variable {dot over (x)} isdependent on u by B_(p) and dependent on x by A_(p). Lastly, u and x areindependent of any of the nodes.

The dependency graph 300 may represent the dependencies in a modelblock. It is noted that the nodes for x and x are internal nodes thatmay not be directly accessed from outside the model block. On the otherhand, the nodes for u and y may be used to connect the model block withother model blocks.

Graph 300 may be constructed by creating a directed graph treatingvariables x, {dot over (x)}, u and y as nodes, and Jacobian blockpattern matrices A_(p), B_(p), C_(p), and D_(p) as the edges betweenthese nodes. Accordingly, path 300 may represent Jacobian patternmatrices.

Referring back to FIG. 2, according to an illustrative embodiment, todetermine Jacobian block pattern A_(p) of the model 200, Jacobianpatterns of the model blocks are first determined. Beginning with theintegrator model blocks 210, 212, 214, the equations for an integratormodel block are given below:

$\begin{matrix}\left\{ \begin{matrix}{\overset{.}{x} = {{0x} + u}} \\{y = {x + {0u}}}\end{matrix} \right. & (8)\end{matrix}$

FIG. 4 illustrates an example data dependency graph of an integratormodel block according to an illustrative embodiment.

Next, for gain model block 218, the equations for a gain model blockwith factor k are:

$\begin{matrix}\left\{ \begin{matrix}{\overset{.}{x} = {{0x} + {0u}}} \\{y = {{0x} + {k\; u}}}\end{matrix} \right. & (9)\end{matrix}$

FIG. 5 illustrates an example data dependency graph of a gain modelblock according to an illustrative embodiment. FIG. 5 does not include anode for {dot over (x)} or x because these variables do not affect thebehavior of the model block, as seen in equations (9).

Lastly, for sum model block 216, the equations for a sum model block (oradd model block) with three inputs are as follows:

$\begin{matrix}\left\{ \begin{matrix}{\overset{.}{x} = {{0x} + {0u}}} \\{y = {{u\; 1} + {u\; 2} + {u\; 3}}}\end{matrix} \right. & (10)\end{matrix}$

FIG. 6 illustrates an example data dependency graph of a sum model blockwith three inputs according to an illustrative embodiment. FIG. 6 alsodoes not include a node for {dot over (x)} or x because these variablesdo not affect the behavior of the block, as seen in equations (10).

FIG. 7 illustrates an example data dependency graph 700 of the entiremodel 200 of FIG. 2 according to an illustrative embodiment. Theindividual data dependency graphs representing block Jacobian patternsfor the model blocks may be connected together to form the graph of theentire model. The data dependency graph of the entire model mayrepresent an open loop Jacobian pattern.

An open-loop Jacobian pattern may be a Boolean-valued matrix defined fora portion of a model (e.g., a block diagram). For example, suppose themodel blocks in the portion are given as the ordered set {blk₁, blk₂, .. . , blk_(n)}, the open-loop Jacobian pattern may be defined as

$\begin{matrix}{J_{p}^{o} = \begin{bmatrix}A_{p}^{o} & 0 & B_{p}^{o} & 0 \\C_{p}^{o} & 0 & D_{p}^{o} & 0 \\0 & E_{p}^{o} & 0 & F_{p}^{o} \\0 & G_{p}^{o} & 0 & H_{p}^{o}\end{bmatrix}} & (11)\end{matrix}$

where O means open-loop and:

$\begin{matrix}{A_{p}^{o} = \begin{bmatrix}A_{p,1}^{o} & 0 & 0 \\0 & \ddots & 0 \\0 & 0 & A_{p,n}^{o}\end{bmatrix}} & (12)\end{matrix}$

A_(p,j) ^(o), j=1, 2, . . . , n A_(p,j), j=1, 2, . . . , n are Jacobianblock matrices A_(p) A_(p) ^(o) of the model blocks 1 through n in themodel.

Similarly, we have:

$\begin{matrix}{B_{p}^{o} = \begin{bmatrix}B_{p,1}^{o} & 0 & 0 \\0 & \ddots & 0 \\0 & 0 & B_{p,n}^{o}\end{bmatrix}} & (13)\end{matrix}$ $\begin{matrix}{C_{p}^{o} = \begin{bmatrix}C_{p,1}^{o} & 0 & 0 \\0 & \ddots & 0 \\0 & 0 & C_{p,n}^{o}\end{bmatrix}} & (14)\end{matrix}$ $\begin{matrix}{D_{p}^{o} = \begin{bmatrix}D_{p,1}^{o} & 0 & 0 \\0 & \ddots & 0 \\0 & 0 & D_{p,n}^{o}\end{bmatrix}} & (15)\end{matrix}$

The open loop Jacobian pattern of a model may be determined based on adata dependency graph. There are several ways to generate the graph of areceived model. One embodiment to generate a graph is to use anadjacency matrix. An adjacency matrix may be a matrix representing whichnodes of a graph are connected to which other nodes. The graph of model110 may be represented as the following matrix:

TABLE-1 J_(p) ^(O): Adjacency matrix of the data dependency graph of ablock diagram model: X Y_(b) U_(b) U_(root)Y_(root) {dot over (X)} A_(p)^(O) 0 B_(p) ^(O) 0 Y_(b) C_(p) ^(O) 0 D_(p) ^(O) 0 U_(b) 0 E_(p) ^(o) E0 F_(p) ^(o) F Y_(root)U_(root) 0 G_(p) ^(o) G 0 H_(p) ^(o) H

The E_(p) ^(o), F_(p) ^(o), G_(p) ^(o), H_(p) ^(o) matrices describe theinterconnections among model block inputs, U_(b), model block outputs,Y_(b), and model inputs, U_(root,) and model outputs Y_(root) Of themodel.

Adjacency matrix J_(p) ^(O) may be generated by assembling A_(p) ^(o),B_(p) ^(o), C_(p) ^(o), D_(p) ^(o) from the Jacobian block patternmatrices and the E_(p) ^(o), F_(p) ^(o), G_(p) ^(o), H_(p) ^(o)matrices.

The open-loop Jacobian pattern of a model may be used to determine aclosed loop Jacobian pattern of the model. The closed loop Jacobianpattern may be distinguished from the open loop Jacobian pattern as theclosed loop Jacobian pattern may represent dependencies betweenvariables in the model.

Suppose a portion of a model (e.g., represented by a block diagram) isgiven as x=ƒ(y) q=ƒ(z), where q and z are vectors of variables, whichcontain either algebraic variables (e.g., u), state variables (e.g., x),or the time derivatives of state variables (e.g., {dot over (x)}), theclosed-loop Jacobian pattern of the portion is then defined as j_(p)^(o)=└e_(i,j)┘, where the elements of the matrix are defined as:

$\begin{matrix}{e_{i,j} = \left\{ \begin{matrix}{1,} & {{if}\mspace{14mu} y_{i}\mspace{14mu} {is}\mspace{14mu} {dependent}\mspace{20mu} {on}\mspace{14mu} x_{j}} \\{0,} & {otherwise}\end{matrix} \right.} & (16)\end{matrix}$

From the open loop Jacobian pattern J_(p) ^(O), the transitive closurebetween nodes in the adjacency matrix may be found to obtain acorresponding closed loop Jacobian pattern for the model with Jacobianblock pattern matrices, A_(p) ^(c), B_(p) ^(c), C_(p) ^(c), and D_(p)^(c), where the superscript c may stand for closed. The transitiveclosure between {dot over (x)} {dot over (x)}_(m) and x x_(n) yieldsA_(p) ^(c). The transitive closure between {dot over (x)} {dot over(x)}_(m) and u_(root)u_(root) _(—) _(n) yields B_(p) ^(c). Thetransitive closure between x x_(m) and y_(root)y_(root) _(—) _(n) yieldsC. The transitive closure between y_(root) and u_(root) yields D_(p)^(c).

A closed loop Jacobian pattern may be determined by determination tool112 using the data dependency graph of the entire model. For example,determining whether {dot over (x)} is dependent on x in the entire modelmay be based on determining if {dot over (x)}_(m) can be reached fromx_(n) in the data dependency graph. Determining if {dot over (x)}_(m)can be reached from x_(n) may be done by applying a search algorithm.

By way of example, a search algorithm may be implemented as follows forgraph 700 of model 200. Starting from a node trace back to see if anystate x_(n) can be reached. For example,:

-   -   a. {dot over (x)}₁ is dependent on u₁ (the connection between        {dot over (x)}₁ and u₁ is B_(p) C_(p)),    -   b. u₁ is driven by y₄. y₄ is dependent on u₄₋₁, u₄₋₂, and u₄₋₃        (the connections between them are D_(p,11), D_(p,21), D_(p,31)        of sum model block 216, which are Dp1, Dp2, and Dp3 in FIG. 7,        respectively),    -   u₄₋₁, u₄₋₂, u₄₋₃ are dependent on y₁, y₂, y₃, respectively        (connected through an E matrix, which describes the connections        between inputs of model blocks and outputs of model blocks), and    -   d. y₁, y₂, y₃ are dependent on x₁, x₂, x₃, (through the C_(p)        matrix of the respective integrators 210, 212, and 214).

Using the example, it can be determined that {dot over (x)}₁, can bereached from x₁, x₂, x₃.

Similar procedures may be applied to {dot over (x)}₂ and to {dot over(x)}₃. Accordingly, it may be determined that {dot over (x)}₂ is onlyreachable from x₂, and that {dot over (x)}₃ is only reachable from x₁.Thus, the closed loop Jacobian block pattern matrix A_(p) ^(c) ofexample model 200 may be:

$\begin{matrix}{A_{p}^{o} = \begin{bmatrix}1 & 1 & 1 \\0 & 1 & 0 \\1 & 0 & 0\end{bmatrix}} & (17)\end{matrix}$

Procedures similar to the procedure to find A_(p) ^(c), as describedabove, may be applied to find B_(p) ^(c), C_(p) ^(c), and D_(p) ^(c).

The search algorithm may be such that it identifies reachability betweennodes (e.g., one of a depth first search, breadth first search, and A*search):

A _(p) ^(c) :{dot over (x)}→x

B _(p) ^(c) :{dot over (x)}→u _(root)

C _(p) ^(c) :y _(root) →x

D _(p) ^(c) :y _(root) →U _(root) A _(p) ^(c) :{dot over (x)} _(n) →x_(n) B _(p) ^(c) :{dot over (x)} _(m) →u _(root) _(—) _(n) C _(p) ^(c):y _(root) _(—) _(m) →x _(n) D _(p) ^(c) :y _(root) _(—) _(m) →u _(root)_(—) _(n)  (18)

where u_(root) u_(root) _(—) _(n) is an input of the model, y_(root)y_(root) _(—) _(n) is an output of the model. For simplicity, the aboveexample described in reference to FIG. 7 does not have modelinput/output.

Accordingly, A_(p) ^(c) (i,j)=1 means there is a directed path thatconnects x_(j) to {dot over (x)}_(i). B_(p) ^(c)(i,j)=1 means there is adirected path that connects u_(root) _(—) _(j) to x_(i). C_(p)^(c)(i,j)=1 means there is a directed path that connects x_(j) tovroot_(i)x_(i). D_(p) ^(c)(i,j)=1 means there is a directed path thatconnects u_(root) _(—) _(j) to y_(rooti)x₁.

In the case of a hierarchical block diagram model, a closed loopJacobian pattern of a first portion of the model may be hierarchicallydetermined by treating a second portion of the model as a model blockwithin the first portion. Therefore, the closed loop Jacobian pattern ofthe second portion may then be considered to be the Jacobian blockpatterns of a model block within the first portion representing thesecond portion.

Example Processing for Data Dependency Visualization

FIG. 8 illustrates exemplary processing 800 for visualizing datadependency information according to an illustrative embodiment.

Determination tool 112 may receive a block diagram model (act 810).Determination tool 112 may receive either a portion of the model or theentire model.

Determination tool 112 may determine Jacobian block patterns of themodel (act 820). Jacobian block patterns may be determined based ondetermining one or more Jacobian block patterns for one or morecorresponding model blocks in the model. A Jacobian block pattern of amodel block may be determined based on retrieving a user pre-definedpattern for the model block.

Determination tool 112 may determine an open loop Jacobian pattern ofthe model (act 830). The open loop Jacobian pattern may be determinedbased on the Jacobian block patterns of the blocks in either a portionof the model or the entire model.

Determination tool 112 may determine a closed loop Jacobian pattern ofeither a portion of the model or the entire model (act 840). The closedloop Jacobian pattern of the model may be determined based on the openloop Jacobian pattern.

Visualization tool 120 may indicate (e.g., display) data dependencies ofthe model (act 850). Visualization tool 120 may indicate (e.g., display)data dependences based on the closed loop Jacobian pattern determined bydetermination tool 120.

In another embodiment, Jacobian block patterns may be determined basedon based on semantic representations. An example of a semanticrepresentation may include a control flow graph. A control flow graph(CFG) may be a representation (e.g., using graph notation) of all pathsthat may be traversed through a software program during its execution. Asemantic representation may also include a data flow graph. A data flowgraph (DFG) may be a representation (e.g., using graph notation) of allpaths along which data can be communicated between nodes during anexecution of the computations that the DFG represents. A semanticrepresentation may also include a combination of control flow and dataflow graphs, or a net list (e.g., a list of entities such ascomputations and the connections between these entities). In anembodiment the various semantic representations may be in-memoryrepresentations only (e.g., an intermediate representation).

The semantic representation of a model block in the received blockdiagram model may be determined computationally by determination tool112. In the case where the semantic representation is a CFG, the CFG canbe generated based on a function, for example, a code generationfunction of Real Time Workshop® product, a product of MathWorks, Natick,Mass. The Real Time Workshop® product code generation function (RTWCGF)may be pre-defined by a user. The RTWCGF may be used to generate a CFGof an output function (e.g., g in equations (1)), derivative function(e.g., ƒ in equations (1)), or an update function (e.g., thediscrete-time equivalent of ƒ in equations (1)).

The functions, and thus the CFG, may also correspond with a portion of ablock diagram model or an entire block diagram model. If the functionstreat an entire block diagram model as a block, the Jacobian blockpatterns determined based on the semantic representation may be a closedloop Jacobian pattern of the entire block diagram model. Similarly,treating a portion of the block diagram model as a block may determine aJacobian block pattern that is the closed loop Jacobian pattern of theportion of the block diagram model.

FIG. 9 illustrates an example block diagram model 900 according to anillustrative embodiment. Model 900 illustrates a function ZZZ 902receiving two inputs, u1 and u2 and returning two outputs, y1 and y2.Model 900 also has two outputs, Out1 and Out2. In the example, thesource code of function ZZZ 902 written by a block author (e.g., user orother computations) may be:

function [y1,y2]=fcn(u1,u2)

k=u2/3;

y1=u1̂2;

y2=k*u1.  (19)

The source code of function ZZZ 902 may also be represented as asemantic representation.

FIG. 10 illustrates a graphical representation 1000 of a combinedcontrol flow/data flow graph (CDFG) of function ZZZ 902 according to anillustrative embodiment. As seen in graphical representation 1000, thecontrol flow enters at the “=” node 1004. This node represents astatement y1=pow(u1,2) that may be represented by data flow. In theCDFG, this statement is shown by node “y1” 1002 connected to node “=”1004. Node “y1”, in turn, is connected to the ‘pow’ operationrepresented by node “pow” 1020. The node “pow” 1020 is an operation thatis connected to its two input variables represented by node “u1” 1006and node “2” 1008. Traversing the data flow graph that corresponds tonode “=” 1004 from node “=” 1004 onwards reveals that node “y1” 1002 isindirectly connected to node “u1” 1006. Accordingly, node “y1” 1002 isdependent on node “u1” 1006. The control flow then reaches the next “=”node 1010 that represents a statement y2=(u2/3)*u1 that may berepresented by data flow. The corresponding data flow graphrepresentation 1000 shows node “y2” 1012 depends on u1 1014 and u2 1016.The control flow then exits the CFDG 1000.

The generated CDFG may be used to determine the Jacobian block pattern.The CDFG may be traversed to determine the dependencies of the variableswithin the CDFG. For example, in FIG. 10, a traversal beginning at node“y1” 1002 to node “pow” 1020 and finally to node “u1” 1006 shows y1 isdependent on u1. The CDFG may also be used to determine which variablesare in the transitive closure of a given variable. For example, the CDFGmay be used to determine that node “u1” 1014 and node “u2” 1016 are inthe transitive closure of node “y2” 1012. The variable y2 may then bedetermined to be dependent on variable u1 and variable u2. The CDFGtraversal may include following references such as labeled references.For example, the variable u1 is referenced by node “u1” 1006 and node“u1” 1014. Traversing the graph may include resolving this reference bytracing from one node in the graph to another that is referenced or thatrepresents the same variable.

FIG. 11 illustrates an example graphical representation 1100 of aJacobian pattern for a model block based on the dependencies in functionZZZ 902 in FIG. 9 according to an illustrative embodiment. Thedependencies are between y1, y2, u1, and u2. As can be seen in graphicalrepresentation 1100, output y1 1102 depends on input u1 1104, and outputy2 1106 depends on both input u1 1104 and input u2 1108. Thecorresponding Jacobian block pattern d_(p) matrix for the model blockis:

[1 0; 1 1]  (20)

Example Processing Technique for Generating Symbolic Equation Structures

A closed loop Jacobian may be used to generate symbolic equationstructures. Symbolic equation structures may symbolically represent datadependencies in a block diagram model. An example structure of asymbolic equation may be:

{dot over (x)} ₁ =f ₁(x ₁ ,x ₂ ,x ₃)

{dot over (x)} ₂ =f ₂(x ₂)

{dot over (x)}₃ =f ₃(x ₁)  (21)

The closed loop Jacobian block matrices A_(p) ^(c) and B_(p) ^(c) may beused to generate the structure of the derivative and/or update method ofthe model and the closed loop Jacobian block matrices C_(p) ^(c) andD_(p) ^(c) may be used to generate the structure of the output method.A_(p) ^(c)(i,j)=1 may mean that x_(j) appears in the right hand side ofthe equation to compute {dot over (x)}_(i). The example structure ofsymbolic equations may represent the symbolic equations for model 200shown in FIG. 2. In this example, the model has no model input andoutput port. Thus, A_(p) ^(c) is the only matrix necessary to generatethe structure of the equations for model 200.

FIG. 12 illustrates an example block diagram model 1200 according to anillustrative embodiment. A portion of model 1200 is defined by boundary1202. The portion of model 1200 may be treated as subsystem 1204 with aninput port 1206 and an output port 1208. As subsystem 1204 has bothinput port 1206 and output port 1208, the closed-loop Jacobian blockpattern matrices A_(p) ^(c), B_(p) ^(c), C_(p) ^(c), D_(p) ^(c) for themodel block that represents subsystem 1204 may all be needed to generatesymbolic equation structures of model 1200.

Example Processing Technique for Visualizing Data Dependencies

Determined data dependencies may be indicated to users in a number ofways.

FIG. 13 illustrates exemplary processing 1300 for indicating datadependencies in a visualization according to an illustrative embodiment.The visualization may be a data dependency graph visualization. FIG. 2previously described may be considered a data dependency graphvisualization. As previously discussed, dependencies between the blocks(e.g., data dependency paths) may be indicated, for example byhighlighting portions of model 200.

According to FIG. 13, data dependency visualization tool 120 may firstinteract with a model (act 1310). Interacting with the model may includeone or more of the steps shown in the example processes of FIG. 8.

A user selection may then be received (act 1320). The user selection mayidentify a first portion of a visual representation of the model. Forexample, a user may click on a connection between blocks. Receiving theuser selection may include receiving an identification of one or morevariables in the model.

A second portion of the visual presentation that is data dependent onthe first portion of the visual representation may then be determined(act 1330). The determining may be performed using Jacobian patterns ofthe model and/or of the model blocks. For example, a block with an inputconnected to the selected connection in the Jacobian pattern may bedetermined to be data dependent on the selected connection.

The determined second portion of the visual representation may then beindicated (act 1340) for example by highlighting. Highlighting mayinclude distinguishing visually. Highlighting may include, for example,coloring, resizing, moving, outlining, blinking, lowlighting, labeling,etc. For example, the block determined to be data dependent may becolored orange.

A pattern in the Jacobian patterns of the model and/or of the modelblocks may then be identified (act 1350). For example, determinationtool 112 may identify a pattern indicating a third portion of the visualrepresentation is dependent on another portion of the visualrepresentation. A third portion of the visual representation may then behighlighted by visualization tool 120 based on the pattern (act 1360).

Models may be noncausal and include connections with multiple variablesbetween blocks. The Jacobian pattern may be shown for the variousvariables in one connection in different colors. For example, if a userselects a noncausal connection that represents a force/velocity pair,this may result in the highlighting of force data dependencies in blueand velocity dependencies in green.

FIGS. 14-16 illustrate examples of visualizations of an electricalcircuit model according to an illustrative embodiment.

FIG. 14 illustrates example block diagram model 1400 of an electricalcircuit according to an illustrative embodiment. Model 1400 includes aseries connection of a battery, Vd 1402, a resistor, R1 1404, aresistor, R2 1406, a capacitor, C2 1408, and a ground node, GND 1410.These electrical circuit elements may have the following equationsassociated with them. Vd: v_vd=Vd, R1: v_r1=R1*i_r1, R2: v_r2=R2*i_r2,C: di_c/dt=C*v_c, GND: v_gnd=0. Furthermore, the connections between theelements may result in a number of equations according to Kirchhoff'scurrent law (i_vd=i_r1, i_r1=i_r2, i_r2=i_c, i_gnd=i_c) and Kirchhoff'svoltage law (v_vd−v_r1−v_r2−v_c−v_gnd=0). The blocks in model 1400 maybe the electrical circuit elements and their equations may determinetheir block Jacobian patterns. For example, the block Jacobian patternfor R1 1404 may have as input variable u the value of v_r1 and outputvariable y the value of i_r1. Accordingly, the Jacobian block patternmatrix D_(p) for model block R1 1404 may be [1]. The Jacobian patternmatrix for R2 1406 may have as input variable u the value of i_r2 andoutput variable y the value of v_r2. Accordingly, the Jacobian blockpattern matrix D_(p) for model block R2 1406 may also be [1].

In another formulation, the input variables of R1 1404 may be an array[v_r1; i_r1] and the output variables may be an array [v_r1; i_r1]. TheJacobian block pattern matrix D_(p) for model block R1 1404 may now be[0 1; 0 0] or [0 0; 1 0], depending on whether the block equationscompute v_r1 or i_r1 as output, respectively. The Jacobian patternmatrix and/or some of the Jacobian block pattern matrices may bevisualized in model 1400.

FIG. 15 illustrates model 1400 showing dependency in model 1400according to an illustrative embodiment. Model 1400 shows Jacobian blockpattern matrix D_(p) for model block R1 1404. This visualization may bein response to a user action, for example, moving a cursor over R1 1404.In another embodiment, if the input, output, states, and derivatives ofa block are given, only the Jacobian pattern matrices may be shown. Thisvisualization may be, for example, a dot pattern, binary pattern,Boolean pattern, etc.

Jacobian patterns for blocks with noncausal equations may be derived bydetermination tool 112 based on analysis of the equations that arepresent in model 1400 to determine an ordering that allows solving theseequations. Equations that do not have a variable that is explicitlycomputed by the equation may be called noncausal or acausal. A noncausalequation may be formulated implicitly, for example by enforcing aright-hand or left-hand side of value 0.

The closed loop Jacobian pattern may indicate the presence of cyclicrelations that may represent an algebraic loop. For example, theJacobian block pattern matrix D_(p) for model block R1 1404 may be [0 1;0 0] and for model block R2 1406 may be [0 0; 1 0] Along with theconnection pattern [i_r1; i_r2; v_r1; v_r2]=[0 1 0 0;1 0 0 0;0 0 0 1; 00 1 0] [i_r1; i_r2; v_r1; v_r2], a closed loop Jacobian pattern may bederived such that [i_r2; v_r1]=[0 1;1 0] [i_r2; v_r1]. This closed loopJacobian pattern may indicate that i_r2 depends on v_r1 and that v_r1depends on i_r2, which indicates a cyclic data dependency.

Cyclic data dependencies may be indicated differently than dependenciesthat are not part of a cycle.

Visualization of data dependencies of models with noncausal equationsmay include indicating which variables are computed by, for example,which equations, which blocks, or which ports, etc.

FIG. 16 illustrates model 1400 showing a cyclic relationship accordingto an illustrative embodiment. In addition to indicating output valuesof a model element, if there is a dependency on an input value asindicated by the Jacobian block matrix D, the corresponding input valuemay also be indicated. All model blocks may indicate which values aretheir output values. In addition, or alternatively, model blocks R1 1404and R2 1406 may show their input values (i_r2 1604 and v_r1 1602,respectively) to indicate the model blocks have a cyclic dependency.

Another interaction may be based on a ‘view mode’. If a user switchesfrom the regular model view mode to a Jacobian pattern view mode, allmodel blocks and connections may be replaced by their Jacobian patternand/or data dependency relations, e.g., as a data dependency path.

FIG. 17 illustrates a model view mode of model 1700 according to anillustrative embodiment. Model 1700 includes three model blocks,Integrator model block 1702, Gain model block 1704, and Add model block1706. These model blocks perform operations on two inputs, In1 1710 andIn2 1712, to produce one output, Out1 1720. Integrator model block 1702integrates the input from In1 1710 with respect to time. Gain modelblock 1704 multiplies the input from In2 1712 with a factor K. Add modelblock 1706 adds the results from Integrator model block 1702 and Gainmodel block 1704. Output Out1 1720 equals the result from Add modelblock 1706. The Jacobian block pattern matrices D_(p) for model blocksIntegrator 1702, Gain 1704, and Add 1706 may be determined to be [0],[1], and [1 1], respectively. In an embodiment, the blocks may bereplaced by their Jacobian pattern or Jacobian pattern matrices.

FIG. 18 illustrates a Jacobian pattern view mode of model 1800 accordingto an illustrative embodiment. As seen in FIG. 18, the icons ofIntegrator model block 1702, Gain model block 1704, and Add model block1706 are replaced by respective representations of their Jacobian blockpattern matrices D_(p), namely Integrator 1802, Gain 1804, and Add17806. In another embodiment, connected model elements may be replacedby their open loop or closed loop pattern Jacobian and/or Jacobianpattern matrices.

A user may also identify certain variables in the block diagram modeland the different data dependency paths for the variables may then behighlighted.

FIG. 19 illustrates an example user interface 1900 displaying multiplevisualizations according to an illustrative embodiment. User interface1900 may include two or more panes. User interface 1900 may be dividedinto panes 1910, 1920, 1930, and 1940. A pane may represent a quadrantof the user interface 1900.

Pane 1910 may be located in the upper left of the user interface 1900and may depict a dot Jacobian pattern visualization. Pane 1920 may belocated in the upper right of the user interface 1900 and may depict adata dependency path-based representation. In the representation arrows1924 and 1926 and sum block 1922 may be colored orange and integrator1928 colored green to indicate dependency between adder 1922 andintegrator 1928. Pane 1930 may be located in the lower right of the userinterface 1900 and may depict a data dependency diagram. Lastly, pane1940 may be located in the lower left of the user interface 1900 and maydepict symbolic equations.

A user interface containing multiple panes may permit a user to betterunderstand data dependencies in a block diagram model. User interactionbetween the various panes may be linked. For example, selecting aportion of a visualization in one pane may highlight a correspondingportion of a visualization in another pane. As seen in FIG. 19, pane1920 and pane 1930 both include corresponding highlights. Pane 1910 andpane 1940 may also be correspondingly highlighted.

FIG. 20 illustrates an example dot Jacobian pattern visualization 2000as may be displayed in pane 1910 according to an illustrativeembodiment. Dot pattern visualization 2000 depicts x values onhorizontal axis 2010 and {dot over (x)}values on vertical axis 2012.Dots in dot pattern visualization 2000 may correspond to the presence ofa dependency of {dot over (x)} on x, which may be represented by thevalue of one in the Jacobian block pattern matrix A_(p). The display ofdot pattern visualization 2000 may allow users to quickly determinedependencies in a block diagram model.

In the illustrative example, dot pattern visualization 2000 representsthe closed-loop Jacobian block pattern matrix below:

$\begin{matrix}{A_{p}^{o} = \begin{bmatrix}1 & 1 & 1 \\0 & 1 & 0 \\1 & 0 & 0\end{bmatrix}} & (22)\end{matrix}$

For example, dots 2020, 2022, and 2024 in the top row corresponding to{dot over (x)}₁ show that {dot over (x)}, is dependent on x₁, x₂, andx₃. In an example, if a user hovers a cursor over dot 2024, a tooltipmay be displayed stating that {dot over (x)}₁ is dependent on x₃.

Dot pattern visualization may also represent non-binary values, forexample, the strength of a data dependency. This strength may be basedon the numerical value of an entry in the Jacobian matrix. Strength ofdata dependency may be shown by differing size, color, shape, etc. ofthe dots and/or other than by dots such as, for example, numericalvalues. In addition, the visualization may account for the sign of adependency and whether it includes an imaginary part.

Model aspects may be shown on a Jacobian pattern visualization such asdot pattern visualization 2000. Model aspects may include values ofvariables. For example, values of variables at a given point in time maybe shown in the Jacobian pattern visualization and may provide furtherinformation, such as, for example, all blocks in the path from x₃ to{dot over (x)}₁. In an embodiment the model aspects may be displayed,for example, in a tooltip that appears when the user hovers a mouse overa dot.

FIG. 21 illustrates model 2100 visualizing model aspects according to anillustrative embodiment. Model 2100 shows Gain model block 2102 replacedby its Jacobian block pattern matrix D_(p). If the value K of the gainis time dependent, then the value of the corresponding entry in theJacobian may change. This value may be shown during execution of model2100. For example, the value of the entry in the Jacobian block matrix Dfor Gain model block 2102 is shown as 4.15 in a superimposed field. Thevisualization may take many forms such as, for example, displaying thematrix values inside block 2102.

Users may also interact with the model through the Jacobian patternvisualization. For example, breakpoints for debugging may be set byinteracting with the Jacobian pattern visualization. For example, usingmodel 2100 in FIG. 21, the display of the value 4.15 may be selected andinformation entered to halt or break execution when the value exceeds 5.For example, the user may type “>5”. During further execution when thevalue of the corresponding entry of the D matrix exceeds 5, theexecution may be halted. This information may be visualized. Forexample, the dot in the dot pattern may take on a different coloring toindicate it is associated with a debug breakpoint. In another example,the user may associate breakpoints with the Jacobian, the Jacobian blockmatrices A, B, C, D, the Jacobian pattern, the Jacobian block patternmatrices A_(p), B_(p), C_(p), D_(p), the closed loop Jacobian patternmatrix, the closed loop Jacobian block pattern matrices A_(p) ^(c),B_(p) ^(c), C_(p) ^(c), D_(p) ^(c), etc.

In another embodiment, model blocks may provide information about theirJacobian, Jacobian pattern, Jacobian block matrices A, B, C, D, etc. asoutput, for example during execution. Further model blocks may then havethis output as input for further computations. The output may bevisualized as a port on a block. The block may be depicted differentlyfrom other ports to indicate the nature of the information that itprovides.

In yet another embodiment models may store information about theirJacobian, Jacobian pattern, Jacobian block matrices A, B, C, D, etc. ina workspace (e.g., a global or a model workspace), for example duringexecution.

Visualizations may be hierarchical. As an example of hierarchicalvisualization, dot pattern visualization 2100 may show a Jacobianpattern of a portion of a block diagram model at a certain level ofhierarchy in the model. Then, if the user hovers a cursor over an entry,or selects the entry, the Jacobian pattern of the content of the nextlevel in the model hierarchy, or in general the content of acorresponding block, may be shown.

FIG. 22 illustrates hierarchical visualization 2200 of model 1200 in anillustrative embodiment. In hierarchical visualization 2200, first leveldot pattern visualization 2210 may have a dot indicating dependencebetween an input and output. If the dot is selected (e.g., clicked,double-clicked, activated, etc.), a second dot pattern visualization2220 may be displayed which represents a next hierarchical level wherethe one input and output may be decomposed into variables that theycontain. Second dot pattern visualization 2220 may show how thosevariables are related.

For example, when dot 2212, which is a connection from {dot over (x)}₃to x₃ in the top layer, is clicked, the open loop Jacobian of thesubsystem that contains x₃ may appear. The open loop Jacobian maycontain the [A B C D] matrix of the subsystem.

FIG. 23 illustrates example data dependency diagram visualization 2300that may be displayed in pane 1930 according to an illustrativeembodiment. Data dependency diagram visualization 2300 may display agraph view of dependencies in a block diagram model. Nodes in the graphview may correspond to an input, output, derivative, or state in theblock diagram model. The nodes may be connected based on thedependencies between the nodes.

Visualization 2300 may also support user interactivity. For example,data dependency in visualization 2300 may be highlighted based on userselections. A user may select a node in visualization 2300. The selectednode may then be colored in a first color. Nodes dependent on theselected node may then be colored in a second color. Lastly, any nodesthat the selected node is dependent on may be colored in a third color.Other embodiments may use shading, varying line widths, cross-hatching,or other techniques to uniquely identify entities in visualization 2300.In another embodiment, nodes that the selected node depends on may becolored in a fourth color. Nodes that these colored nodes depend on maybe colored in a fifth color.

The particular pattern in visualization 2300 may depict dependencies inthe block diagram model shown in FIG. 2. The text in the node maydescribe what the node represents. For example, node 2310 has the text“Integrator1_o_(—)1.” Accordingly, node 2310 may represent a firstoutput of the first integrator in the block diagram model. In anotherembodiment, the node may indicate further information about acorresponding block such as whether it has a hierarchical layer belowit, whether it is set to generate a function when code is generated,whether a generated function is set to be reusable, etc.

If node 2312 is selected by a user, node 2312 may be displayed in agraphical manner such as, for example, a specific outline, a specificcolor, etc. The arrow from node 2312 to node 2310 indicates that theoutput of integrator1 is dependent on the state of integrator1.Accordingly, node 2310 may, for example, be colored orange to show thatnode 2310 is dependent on node 2312. The same applies to node 2314,2316, and 2318. Node 2320 may, for example, be colored green as node2320 is dependent on selected node 2312.

While coloring is used in data dependency diagram visualization 2300,any other form of highlighting may be used alone or in combination.

Example Processing Technique for Displaying Multiple Visualizations

FIG. 24 illustrates exemplary processing 2400 for describing a techniquefor displaying multiple visualizations according to an illustrativeembodiment.

The process begins with visualization tool 120 interacting with a model(e.g., a block diagram model or a graphical model) (act 2410).Interacting with the model may include one or more of the steps shown inthe example process of FIG. 8.

The model may be displayed in a first pane (act 2420). The model may bedisplayed by a data dependency path.

A matrix of values indicating relationships between the blocks of themodel or a graph indicating the relationships between blocks of themodel may then be displayed in a second pane (act 2430). The matrix ofvalues may be displayed by a dot Jacobian pattern visualization 2000.The graph indicating the relationships between blocks of the model maybe a data dependency diagram visualization 2300.

A matrix of values indicating relationships between the blocks of themodel or a graph indicating the relationships between the blocks of themodel may then be displayed in a third pane (act 2440).

Symbolic equations indicating the relationships between the blocks ofthe model may then be displayed in a fourth pane (act 2450).

A selection indicating a first arbitrary point and a second arbitrarypoint associated with the model may then be received (act 2460). Thefirst and second points may be arbitrarily chosen by a user. Theselection may be received in the first pane or the second pane, forexample.

Information associated with the first arbitrary point and the secondarbitrary point may then be indicated (act 2470). The indicating may bedisplayed in the model when the selection is received via the secondpane and in the matrix of values or the graph when the selection isreceived via the first pane, for example.

Selecting a point corresponding to A_(p) (1,1) in a matrix may result inthe indicating (e.g., highlighting) of the path associated with A_(p)(1,1) in the model. Accordingly, selecting an entry in the matrix viewmay result in a visualization in the model view.

Alternatively, a selection may occur in any of the four panes 2420,2430, 2440, 2450, and indicating may occur in any other pane based onthe selection. Less than four panes may be displayed. For example, twopanes may be displayed pairwise. For example, two of panes 2420, 2430,2440, and 2450 may be displayed.

Example Distributed System

FIG. 25 illustrates distributed environment 2500 that may be configuredto practice an illustrative embodiment. Referring to FIG. 25,environment 2500 may include a client 2510, network 2540, serviceprovider 2550, target environment 2560 and cluster 2570. Note that thedistributed environment illustrated in FIG. 25 is just one example of adistributed environment that may be used. Other distributed environmentsmay include additional devices, fewer devices, or devices inarrangements that differ from the arrangement of environment 2500. Forexample, distributed environment 2500 may be implemented as a computingcloud.

Client 2510 may include a device capable of sending and/or receivinginformation (e.g., data) to and/or from another device, such as targetenvironment 2560. Information may include any type of machine-readableinformation having substantially any format that may be adapted for use,e.g., in one or more networks and/or with one or more devices. Theinformation may include digital information and/or analog information.The information may further be packetized and/or non-packetized. In anembodiment, client 2510 may download data and/or code via network 2540.For example, client 2510 can download code for suggesting correctidentifiers consistent with aspects of the invention.

Client 2510 may be, for example, a desktop computer, a laptop computer,a client computer, a server computer, a mainframe computer, a personaldigital assistant (PDA), a web-enabled cellular telephone, a smartphone, smart sensor/actuator, or another computation or communicationdevice that executes instructions that enable the device to perform oneor more activities and/or generate one or more results.

In an illustrative embodiment, client 2510 may include a technicalcomputing environment (TCE) 2520, modeling software 2530 and analysissoftware 2535. TCE 2520 may include a graphical block diagram modelingenvironment that may be used to design models, execute models, andmanipulate the models in accordance with techniques described herein.TCE 2520 may be graphical-based TCE 100. In other illustrativeembodiments, client 2510 may include other components, applications,etc. Illustrative embodiments of TCE 2520 may containcomputer-executable instructions (e.g., code) and data that areconfigured to implement the TCE. The instructions may includeinstructions configured to implement modeling software 2520 and/orgraphical analysis software 2535. An example embodiment ofgraphical-based TCE 100 may be implemented in a TCE 2520.

Modeling software 2530 and analysis software 2535 may be graphical,textual, or a combination that includes both textual and graphicalcapabilities/features. Modeling software 2530 may includecomputer-executable instructions that allow, e.g., a user to buildand/or execute a model. For example, modeling software 2530 may allow auser to build and execute a time-based model, a state-based model, anevent-based model, a dataflow-based model, etc. Modeling software 2350may include code generation logic which may include hardware and/orsoftware for converting a model into a program or code in a computerprogramming language (e.g., C, C++, SystemC, etc.). In one example, acode generator may accept a model that is created in the core simulationlogic and may generate a hardware description language (HDL). Thegenerated code may be editable using an editor. An execution engine maybe configured to compile and link the generated code to produce an“in-memory executable” version of model. The in-memory executableversion of the model may be used, for example, to simulate, verify,trim, or linearize the model. An example embodiment of the invention maybe implemented as part of modeling software 2530.

Analysis software 2535 may include computer-executable instructions thatallow information in a model to be evaluated. Evaluating a model mayinclude generating tests for the model that satisfy model coverageobjectives (e.g., condition coverage, decision coverage, modifiedcondition/decision coverage, etc.), user-defined objectives, etc. Inaddition, evaluating a model may include proving various modelproperties and generating examples of violations of these properties.Moreover, evaluating a model may include analyzing the model, inaccordance with techniques described herein. In an illustrativeembodiment, analysis software 2535 may include the Simulink® DesignVerifier software which is available from The MathWorks, Inc. An exampleembodiment of the invention may be implemented as part of analysissoftware 2535. Analysis software 2535 may include software for executingthe processes described in the flowcharts of FIGS. 8, 13, and/or 24.

Network 2540 may include any network capable of exchanging informationbetween entities associated with the network, including, for example,client 2510, service provider 2550, target environment 2560 and cluster2570. Exchanged information may include, for example, packet data and/ornon-packet data. Implementations of network 2540 may include local areanetworks (LANs), metropolitan area networks (MANs), wide-area networks(WANs), etc. Information may be exchanged between entities using anynetwork protocol, such as, but not limited to, the Internet Protocol(IP), Asynchronous Transfer Mode (ATM), Synchronous Optical Network(SONET), the User Datagram Protocol (UDP), Institute of Electrical andElectronics Engineers (IEEE) 802.11, etc.

Network 2540 may include various network devices, such as, for example,routers, switches, firewalls, servers, etc. Portions of network 2540 maybe wired (e.g., using wired conductors, optical fibers, etc.) and/orwireless (e.g., free-space optical (FSO), radio frequency (RF), acoustictransmission paths, etc.). Portions of network 2540 may include asubstantially open public network, such as the Internet. Portions ofnetwork 2540 may include a more restricted network, such as a virtualprivate network (VPN). It should be noted that implementations ofnetworks and/or devices operating on networks described herein are notlimited with regards to information carried by the networks, protocolsused in the networks, the architecture/configuration of the networks,etc.

Target environment 2560 may include a device that receives informationfrom client 2510, service provider 2550, or cluster 2570. For example,target environment 2560 may receive executable code from client 2510,where the executable code allows target environment to perform anoperation when the code is executed. Client 2510 may have generated theexecutable code using TCE 2520, modeling software 2530, and/or a codegenerator (not shown in FIG. 25).

Cluster 2570 may include a number of processing resources that performprocessing on behalf of another device, such as client 2510, serviceprovider 2550 and/or target environment 2560. Cluster 2570 may includelogic that manages and/or coordinates the operation of multipleprocessing resources. For example, cluster 2570 may send data to and/orreceive results from these processing resources. In an illustrativeembodiment, cluster 2570 may include units of execution (UEs) 2580 a, b,c, and d (collectively UEs 2580) that may perform processing on behalfof client 2510 and/or another device, such as service provider 2550. Anexample embodiment of the invention may be implemented on one or moreUEs 2580.

UEs 2580 may include hardware, software, or hybrid logic that performsprocessing operations on behalf of TCE 2520. For example, in anillustrative embodiment UEs 2580 may parallel process portions of agraphical model created by user of client 2510. This parallel processingmay include performing analysis on the model, parsing the model intoportions, and/or aggregating results from respective UEs 2580 into asingle result for display to a user at client 2510. UEs 2580 may resideon a single device or chip or on multiple devices or chips. For example,UEs 2580 may be implemented in a single application specific integratedcircuit (ASIC) or in multiple ASICs. Likewise, UEs 2580 can beimplemented in a single computer system using virtualization techniques.Other examples of UEs 2580 may include field programmable gate arrays(FPGAs), complex programmable logic devices (CPLDs), applicationspecific instruction-set processors (ASIPs), microprocessors, etc.

A TCE 2520 may include hardware and/or software based logic thatprovides a computing environment that allows users to perform tasksrelated to disciplines, such as, but not limited to, mathematics,science, engineering, medicine, business, etc., more efficiently than ifthe tasks were performed in another type of computing environment, suchas an environment that required the user to develop code in aconventional programming language, such as C++, C, Fortran, Pascal, etc.

Illustrative Computing Architecture Example System

FIG. 26 illustrates an example of a computer system 2600 that may beconfigured to practice an illustrative embodiment of the invention. Forexample, computer system 2600 may be used to implement client 2510,service provider 2550, target environment 2560, etc. Computer system2600 may include processor 2620, memory 2670, storage device 2640, inputdevice 2610, output device 2660, interconnect 2650 and network interface2680. Processor 2620 may include logic configured to executecomputer-executable instructions that implement illustrative embodimentsof the invention. An example of a processor that may be used with theinvention includes the Pentium processor available from IntelCorporation, Santa, Clara, Calif. The instructions may reside in memory2670 and may include instructions associated with TCE 2520 orgraphical-based TCE 100.

Memory 2670 may be a computer-readable medium that may be configured tostore instructions configured to implement illustrative embodiments ofthe invention. Memory 2670 may be a primary storage accessible toprocessor 2620 and can include a random-access memory (RAM) that mayinclude RAM devices, such as, for example, Dynamic RAM (DRAM) devices,flash memory devices, Static RAM (SRAM) devices, etc. Storage device2640 may include a magnetic disk and/or optical disk and itscorresponding drive for storing information and/or instructions.

Interconnect 2650 may include logic that operatively couples componentsof computer system 2600 together. For example, interconnect 2650 mayallow components to communicate with each other, may provide power tocomponents of computer system 2600, etc. In an illustrative embodimentof computer system 2600, interconnect 2650 may be implemented as a bus.

Input device 2610 may include logic configured to receive informationfor computer system 2600 from, e.g., a user. Illustrative embodiments ofinput device 2610 may include keyboards, cameras, touch sensitive areas(e.g., displays), multi-point input devices, biometric sensing devices,computer mice, trackpads, trackballs, pen-based point devices, etc.Output device 2660 may include logic configured to output informationfrom computer system 2600. Illustrative embodiments of output device2660 may include cathode ray tubes (CRTs), plasma displays,light-emitting diode (LED) displays, liquid crystal displays (LCDs),printers, vacuum florescent displays (VFDs), surface-conductionelectron-emitter displays (SEDs), field emission displays (FEDs), etc.Interaction for the visualization may be based on receiving input from auser via input device 2610 and providing output to a user via outputdevice 2660.

Network interface 2680 may include logic configured to interfacecomputer system 2600 with a network, e.g., network 2540, and may enablecomputer system 2600 to exchange information with other entitiesconnected to the network, such as, for example, service provider 2550,target environment 2560 and cluster 2570. Network interface 2680 may beimplemented as a built-in network adapter, network interface card (NIC),Personal Computer Memory Card International Association (PCMCIA) networkcard, card bus network adapter, wireless network adapter, UniversalSerial Bus (USB) network adapter, modem or any other device suitable forinterfacing computer system 2600 to any type of network.

It should be noted that illustrative embodiments may be implementedusing some combination of hardware and/or software. It should be furthernoted that a computer-readable medium that includes computer-executableinstructions for execution in a processor may be configured to storeillustrative embodiments of the invention. The computer-readable mediummay include volatile memories, non-volatile memories, flash memories,removable discs, non-removable discs and so on. In addition, it shouldbe noted that various electromagnetic signals such as wireless signals,electrical signals carried over a wire, optical signals carried overoptical fiber and the like may be encoded to carry computer-executableinstructions and/or computer data on e.g., a communication network foran illustrative embodiment of the invention.

A hardware unit of execution may include a device (e.g., a hardwareresource) that performs and/or participates in parallel programmingactivities. For example, a hardware unit of execution may perform and/orparticipate in parallel programming activities in response to a requestand/or a task it has received (e.g., received directly or via a proxy).A hardware unit of execution may perform and/or participate insubstantially any type of parallel programming (e.g., task, data, streamprocessing, etc.) using one or more devices. For example, in oneimplementation, a hardware unit of execution may include a singleprocessing device that includes multiple cores, and in anotherimplementation, the hardware unit of execution may include a number ofprocessors 2620. A hardware unit of execution may also be a programmabledevice, such as a field programmable gate array (FPGA), an applicationspecific integrated circuit (ASIC), a digital signal processor (DSP),etc. Devices used in a hardware unit of execution may be arranged insubstantially any configuration (or topology), such as a grid, ring,star, etc. A hardware unit of execution may support one or more threads(or processes) when performing processing operations.

A software unit of execution may include a software resource (e.g., atechnical computing environment [e.g., MATLAB® software], a worker, alab, etc.) that performs and/or participates in parallel programmingactivities. For example, a software unit of execution may perform and/orparticipate in parallel programming activities in response to receipt ofa program and/or one or more portions of the program. In an illustrativeembodiment, a software unit of execution may perform and/or participatein substantially any type of parallel programming using one or morehardware units of execution. Illustrative embodiments of a software unitof execution may support one or more threads and/or processes whenperforming processing operations.

Alternative Illustrative Embodiments

An alternative illustrative embodiment may implement a TCE 2520 usingone or more text-based products. For example, a text-based TCE 2520, maybe implemented using products such as, but not limited to, MATLAB®programming language by The MathWorks, Inc.; Octave; Python; ComsolScript; Mathematica from Wolfram Research, Inc.; Mathcad from MathsoftEngineering & Education Inc.; Maple from Maplesoft; Extend from ImagineThat Inc.; Scilab from The French Institution for Research in ComputerScience and Control (INRIA); Virtuoso from Cadence; or Modelica orDymola from Dassault Systemes.

Other illustrative embodiments may implement a TCE 2520 in agraphically-based TCE 2520 using products such as, but not limited to,Simulink®, Stateflow®, SimEvents™, etc., by The MathWorks, Inc.; VisSimby Visual Solutions; MATRIXx or LabView® by National Instruments; Dymolaby Dynasim; SoftWIRE by Measurement Computing; WiT by DALSA Coreco; VEEPro or SystemVue by Agilent; Vision Program Manager from PPT Vision;Khoros from Khoral Research; Gedae by Gedae, Inc.; Scicos from (INRIA);Virtuoso from Cadence; Rational Rose from IBM; Rhopsody or Tau from IBM;Ptolemy from the University of California at Berkeley; or aspects of aUnified Modeling Language (UML) or SysML environment.

Another alternative illustrative embodiment may be implemented in acombined TCE 2520 that combines features of a text-based andgraphically-based TCE 2520. In one implementation, one TCE 2520 mayoperate on top of the other TCE 2520. For example, a text-based TCE 2520(e.g., MATLAB®) may operate as a foundation and a graphically-based TCE2520 (e.g., Simulink®) may operate on top of MATLAB® and may takeadvantage of text-based features (e.g., commands) to provide a user witha graphical user interface and graphical outputs (e.g., graphicaldisplays for data, dashboards, etc.).

CONCLUSION

Implementations may provide devices and techniques that may be used forthe determination of data dependency.

The foregoing description of example embodiments of the inventionprovides illustration and description, but is not intended to beexhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the invention. Forexample, while a series of acts has been described with regard to FIGS.8, 13, and 24, the order of the acts may be modified in otherimplementations consistent with the principles of the invention.Further, non-dependent acts may be performed in parallel.

In addition, implementations consistent with principles of the inventioncan be implemented using devices and configurations other than thoseillustrated in the figures and described in the specification withoutdeparting from the spirit of the invention. Devices and/or componentsmay be added and/or removed from the implementations of FIGS. 1, 25 and26 depending on specific deployments and/or applications. Further,disclosed implementations may not be limited to any specific combinationof hardware.

Further, certain portions of the invention may be implemented as “logic”that performs one or more functions. This logic may include hardware,such as hardwired logic, an application-specific integrated circuit, afield programmable gate array, a microprocessor, software, wetware, or acombination of hardware and software.

No element, act, or instruction used in the description of the inventionshould be construed as critical or essential to the invention unlessexplicitly described as such. Also, as used herein, the article “a” isintended to include one or more items. Where only one item is intended,the term “one” or similar language is used. Further, the phrase “basedon,” as used herein is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

Headings and/or subheadings used herein are used to segment this patentapplication into portions to facilitate the readability of theapplication. These headings and/or subheadings are not intended todefine or limit the scope of the invention disclosed and/or claimed inthis patent application.

The scope of the invention is defined by the claims and theirequivalents.

1. One or more computer-readable media holding computer-executableinstructions for operating a programming environment using a computer,the media holding one or more instructions for: interacting with a blockdiagram model, where: the interacting includes receiving a first portionof a block diagram model, the block diagram model includes a pluralityof blocks, each of the plurality of blocks represents a set of dynamicequations, and the interacting is performed using the computer;determining relationships between a plurality of: a synthesized input, asynthesized output, a synthesized state, or a synthesized derivative,where the determining: is performed for the first portion of the blockdiagram model, wherein the determining includes: determining a blockJacobian pattern of relationships between two or more of an input, anoutput, a state, or a derivative of a first block of the plurality ofblocks in the graphical model.
 2. The media of claim 1, whereindetermining relationships further comprises: determining a blockJacobian pattern of relationships between two or more of an input, anoutput, a state, or a derivative, of a second block of the plurality ofblocks in the graphical model; determining relationships representingconnections between the first and the second blocks of the plurality ofblocks in the graphical model; and determining an open loop Jacobianpattern for the first portion of the block diagram model based on thedetermined block Jacobian pattern for the first and the second blocks ofthe plurality of blocks, and the relationships representing connectionsbetween the first and the second blocks of the plurality of blocks. 3.The media of claim 2, wherein determining relationships furthercomprises: determining a closed loop Jacobian pattern for the firstportion of the block diagram model based on the determined open loopJacobian pattern.
 4. The media of claim 3, further comprisinginstructions for: receiving a second portion of the block diagram model;and determining a closed loop Jacobian for the second portion of theblock diagram model hierarchically based on the determined closed loopJacobian pattern for the first portion of the block diagram model. 5.The media of claim 1, wherein the dynamic equations comprise: at leastone of a derivative function or an update function; and an outputfunction.
 6. The media of claim 1, wherein the relationships compriseJacobian matrices.
 7. The media of claim 1, wherein the block Jacobianpattern comprises a Boolean Jacobian pattern.
 8. The media of claim 1,wherein the block Jacobian pattern comprises one or more soft zeroes. 9.The media of claim 1, further comprising instructions for displaying avisual representation of the block Jacobian pattern, where the visualrepresentation comprises a dot Jacobian pattern matrix.
 10. The media ofclaim 1, further comprising instructions for displaying a visualrepresentation of the block Jacobian pattern, where the visualrepresentation comprises a data dependency path.
 11. The media of claim1, further comprising instructions for displaying a visualrepresentation of the block Jacobian pattern, where the visualrepresentation comprises a data dependency diagram.
 12. The media ofclaim 1, further comprising instructions for determining a signature ofa symbolic equation for the first portion of the block diagram modelbased on the block Jacobian pattern.
 13. The media of claim 12, furthercomprising instructions for displaying on a display a visualrepresentation of the block Jacobian pattern, where the visualrepresentation comprises a portion of the determined symbolic equation.14. The media of claim 1, wherein one or more characteristics of theblock are defined by text.
 15. The media of claim 1, further comprisinginstructions for updating the block Jacobian pattern during execution ofthe block diagram model.
 16. The media of claim 15, further comprisinginstructions for halting execution based on at least a pre-definedpartial Jacobian pattern.
 17. The media of claim 16, wherein thepredefining is based on user interaction with a Jacobian patternvisualization.
 18. One or more computer-readable media holdingcomputer-executable instructions for operating a programming environmentusing a computer, the media holding one or more instructions for:downloading the instructions of claim 1 to a computer system, which whenexecuted by the computer system causes the computer system to performoperations comprising the downloaded instructions; or providingdownloadable software to a computer system, which when executed by thecomputer system causes the computer system to perform the operations ofclaim
 1. 19. One or more computer-readable media holdingcomputer-executable instructions for operating a programming environmentusing a computer, the media holding one or more instructions for:receiving a user selection, where the user selection identifies a firstportion of a visual representation of a block diagram model; determininga second portion of the visual representation that is data dependent onthe first portion of the visual representation, where the determining isperformed using a Jacobian pattern of the block diagram model; andhighlighting the determined second portion of the visual representation.20. The media of claim 19, wherein the block diagram model comprisesconnections representing two or more variables, wherein highlighting thedetermined second portion of the visual representation compriseshighlighting connections dependent on a first variable in a first colorand highlighting connections dependent on a second variable in a secondcolor. 21-38. (canceled)